-
Notifications
You must be signed in to change notification settings - Fork 47k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Bugfix: Remove extra render pass when reverting to client render #26445
Merged
acdlite
merged 2 commits into
facebook:main
from
acdlite:extra-render-pass-hydration-error
Mar 21, 2023
Merged
Bugfix: Remove extra render pass when reverting to client render #26445
acdlite
merged 2 commits into
facebook:main
from
acdlite:extra-render-pass-hydration-error
Mar 21, 2023
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
I noticed while working on a PR that when an error happens during hydration, and we revert to client rendering, React actually does _two_ additional render passes instead of just one. We didn't notice it earlier because none of our tests happened to assert on how many renders it took to recover, only on the final output. It's possible this extra render pass had other consequences that I'm not aware of, like messing with some assumption in the recoverable errors logic. This adds a test to demonstrate the issue. (One problem is that we don't have much test coverage of this scenario in the first place, which likely would have caught this earlier.)
facebook-github-bot
added
CLA Signed
React Core Team
Opened by a member of the React Core Team
labels
Mar 20, 2023
This fixes the bug described by the previous commit.
acdlite
changed the title
Bug: Extra render pass when reverting to client render
Bugfix: Remove extra render pass when reverting to client render
Mar 20, 2023
Comparing: 0131d0c...31fd817 Critical size changesIncludes critical production bundles, as well as any change greater than 2%:
Significant size changesIncludes any change greater than 0.2%: (No significant changes) |
github-actions bot
pushed a commit
that referenced
this pull request
Mar 21, 2023
) (This was reviewed and approved as part of #26380; I'm extracting it into its own PR so that it can bisected later if it causes an issue.) I noticed while working on a PR that when an error happens during hydration, and we revert to client rendering, React actually does _two_ additional render passes instead of just one. We didn't notice it earlier because none of our tests happened to assert on how many renders it took to recover, only on the final output. It's possible this extra render pass had other consequences that I'm not aware of, like messing with some assumption in the recoverable errors logic. This adds a test to demonstrate the issue. (One problem is that we don't have much test coverage of this scenario in the first place, which likely would have caught this earlier.) DiffTrain build for [77ba161](77ba161)
facebook-github-bot
pushed a commit
to facebook/react-native
that referenced
this pull request
Mar 29, 2023
Summary: This sync includes the following changes: - **[77ba1618a](facebook/react@77ba1618a )**: Bugfix: Remove extra render pass when reverting to client render ([#26445](facebook/react#26445)) //<Andrew Clark>// - **[520f7f3ed](facebook/react@520f7f3ed )**: Refactor ReactDOMComponent to use flatter property operations ([#26433](facebook/react#26433)) //<Sebastian Markbåge>// - **[0131d0cff](facebook/react@0131d0cff )**: Check if suspensey instance resolves in immediate task ([#26427](facebook/react#26427)) //<Andrew Clark>// Changelog: [General][Changed] - React Native sync for revisions 3554c88...77ba161 jest_e2e[run_all_tests] Reviewed By: poteto Differential Revision: D44476026 fbshipit-source-id: c6935d760a068672b714722dee1fd24839c08c4b
jeongshin
pushed a commit
to jeongshin/react-native
that referenced
this pull request
May 7, 2023
Summary: This sync includes the following changes: - **[77ba1618a](facebook/react@77ba1618a )**: Bugfix: Remove extra render pass when reverting to client render ([facebook#26445](facebook/react#26445)) //<Andrew Clark>// - **[520f7f3ed](facebook/react@520f7f3ed )**: Refactor ReactDOMComponent to use flatter property operations ([facebook#26433](facebook/react#26433)) //<Sebastian Markbåge>// - **[0131d0cff](facebook/react@0131d0cff )**: Check if suspensey instance resolves in immediate task ([facebook#26427](facebook/react#26427)) //<Andrew Clark>// Changelog: [General][Changed] - React Native sync for revisions 3554c88...77ba161 jest_e2e[run_all_tests] Reviewed By: poteto Differential Revision: D44476026 fbshipit-source-id: c6935d760a068672b714722dee1fd24839c08c4b
OlimpiaZurek
pushed a commit
to OlimpiaZurek/react-native
that referenced
this pull request
May 22, 2023
Summary: This sync includes the following changes: - **[77ba1618a](facebook/react@77ba1618a )**: Bugfix: Remove extra render pass when reverting to client render ([facebook#26445](facebook/react#26445)) //<Andrew Clark>// - **[520f7f3ed](facebook/react@520f7f3ed )**: Refactor ReactDOMComponent to use flatter property operations ([facebook#26433](facebook/react#26433)) //<Sebastian Markbåge>// - **[0131d0cff](facebook/react@0131d0cff )**: Check if suspensey instance resolves in immediate task ([facebook#26427](facebook/react#26427)) //<Andrew Clark>// Changelog: [General][Changed] - React Native sync for revisions 3554c88...77ba161 jest_e2e[run_all_tests] Reviewed By: poteto Differential Revision: D44476026 fbshipit-source-id: c6935d760a068672b714722dee1fd24839c08c4b
bigfootjon
pushed a commit
that referenced
this pull request
Apr 18, 2024
) (This was reviewed and approved as part of #26380; I'm extracting it into its own PR so that it can bisected later if it causes an issue.) I noticed while working on a PR that when an error happens during hydration, and we revert to client rendering, React actually does _two_ additional render passes instead of just one. We didn't notice it earlier because none of our tests happened to assert on how many renders it took to recover, only on the final output. It's possible this extra render pass had other consequences that I'm not aware of, like messing with some assumption in the recoverable errors logic. This adds a test to demonstrate the issue. (One problem is that we don't have much test coverage of this scenario in the first place, which likely would have caught this earlier.) DiffTrain build for commit 77ba161.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
(This was reviewed and approved as part of #26380; I'm extracting it into its own PR so that it can bisected later if it causes an issue.)
I noticed while working on a PR that when an error happens during hydration, and we revert to client rendering, React actually does two additional render passes instead of just one. We didn't notice it earlier because none of our tests happened to assert on how many renders it took to recover, only on the final output.
It's possible this extra render pass had other consequences that I'm not aware of, like messing with some assumption in the recoverable errors logic.
This adds a test to demonstrate the issue. (One problem is that we don't have much test coverage of this scenario in the first place, which likely would have caught this earlier.)